Computers are utilized in personal, professional, educational and other aspects of life to perform functions and provide services. These functions and services are performed and provided via software that runs on the computers. Historically, software was delivered to computers by manually inserting media into the computer or a peripheral attached thereto and loading the software from the media onto the computer. There was some measure of intrinsic security or reassurance that the software being loaded was from the intended and expected manufacturer thereof based on the physical packaging and the distribution channel, such as a retail outlet or a trusted mail order source.
With the advent and proliferation of the Internet and other hostile networks, software distribution expanded into electronic delivery. Although not so limited, electronic software delivery is especially common with smaller programs, upgrades, patches, and the like. When downloading software electronically over the Internet, however, much of the traditional indicia of the source of such software is missing and/or may be more easily fraudulently imitated. To combat such concerns, the computer software industry has relied on secure protocols such as one or more ciphering mechanisms.
One frequently used cipher mechanism is for the manufacturer of a piece of software code to digitally sign the code. The digital signature serves to ensure that the software code (i) has been produced by the claimed and expected manufacturer (i.e., author authentication) and (ii) as being unaltered during the electronic delivery of the software code (i.e., integrity verification). This digital signature security is enabled using, for example, some public-key infrastructure (PKI) approach. Under such a PKI approach, a user of a computer may have software electronically delivered over the Internet and installed on the computer with increased assurance that the software is not of a false origin and has not been maliciously modified.
One prevalent PKI approach is implemented in accordance with the X.509 standard. With the X.509 standard, a certificate authority facilitates the evidencing of a source of software by issuing a public-key certificate (or certificate) to manufacturers of software code. Each manufacturer of software code uses its certificate to digitally sign its software code to produce signed software code. The signed software code is also significantly more secure from an integrity perspective than unsigned code.
Unfortunately, the certificate can be compromised by theft, corruption, carelessness, and so forth. Once compromised, the certificate can no longer authenticate authorship or evidence data integrity for software code. To prevent the continued use or misuse of a compromised certificate, the certificate is revoked. To revoke a certificate, the certificate authority places the certificate on a certificate revocation list. Once a certificate lands on the certificate revocation list, users of computers are made aware that all software code signed (at least from the time of compromise) are no longer secure and should not be trusted. Hence, anything and everything signed with the compromised certificate (at least after the date of compromise) loses its viability with respect to secure electronic delivery or installation and use.
When a certificate is revoked because it has become compromised, the mechanisms of X.509 are functioning properly because all software code that has been signed by the certificate is indeed suspect and untrustworthy. However, certificates are also revoked when it is determined that software code that was signed by the certificate is faulty. Faulty software code includes code that intrinsically harms a computer or the information therein and code that opens a door through which a malevolent hacker can perform deleteriously exploits. In these situations, many pieces of software code are effectively rendered useless in order to address a single piece of defective software code. This is a frustrating result, which intimates that the mechanisms of X.509 are being applied in an ineffective manner.
Many manufacturers of software address faulty pieces of code by incessantly producing software patches or fixes. Unfortunately, these software patches and fixes are only effective if the users of computers proactively seek out, download, and install them. This reliance on proactive behavior by the users of computers is itself a security risk, especially because time delays between an announcement of a software patch or fix and any ultimate installation thereof introduces unavoidable security holes.
Accordingly, there is a need for schemes and techniques to grow PKI-based approaches to software code security and management and/or to address the handling of software code that is determined to be defective.